home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / urn / urn-archives / urn-ietf.archive.9610 / 000134_owner-urn-ietf _Thu Oct 31 08:16:32 1996.msg < prev    next >
Internet Message Format  |  1997-02-19  |  2KB
  1. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id IAA11990 for urn-ietf-out; Thu, 31 Oct 1996 08:16:32 -0500
  2. Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id IAA11985 for <urn-ietf@services.bunyip.com>; Thu, 31 Oct 1996 08:16:25 -0500
  3. Received: from dns2.noc.best.net by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
  4.         id AA21785  (mail destined for urn-ietf@services.bunyip.com); Thu, 31 Oct 96 08:16:23 -0500
  5. Received: from shellx.best.com (shellx.best.com [206.86.0.11]) by dns2.noc.best.net (8.6.12/8.6.5) with SMTP id FAA25128; Thu, 31 Oct 1996 05:15:43 -0800
  6. Date: Thu, 31 Oct 1996 05:15:43 -0800 (PST)
  7. From: "Gregory J. Woodhouse" <gjw@wnetc.com>
  8. To: Martin J Duerst <mduerst@ifi.unizh.ch>
  9. Cc: jayhawk@ds.internic.net, urn-ietf@bunyip.com
  10. Subject: Re: [URN] New syntax draft (was: no subject)
  11. In-Reply-To: <"josef.ifi..728:31.09.96.10.58.37"@ifi.unizh.ch>
  12. Message-Id: <Pine.SGI.3.95.961031050249.19154D-100000@shellx.best.com>
  13. X-Url: http://www.wnetc.com/
  14. Mime-Version: 1.0
  15. Content-Type: TEXT/PLAIN; charset=US-ASCII
  16. Sender: owner-urn-ietf@services.bunyip.com
  17. Precedence: bulk
  18. Reply-To: "Gregory J. Woodhouse" <gjw@wnetc.com>
  19. Errors-To: owner-urn-ietf@bunyip.com
  20.  
  21. By %encoding I assume you mean hex encoding of non-ASCII or non-safe bytes.
  22. Is there an official name for this encoding scheme? I've seen it called URL
  23. encoding, but that hardly seems satisfactory.
  24.  
  25. I'm also concerned because decoding requires knowledge that the string
  26. being decoded is UTF-8. I said before that I wasn't terribly excited about
  27. using RFC 1522 style encodings, but it seems essential in this case because
  28. otherwise the UA has no way of knowing (except by guessing) that the string
  29. is encoded UTF-8 and not just an ASCII string. It is conceivable that some
  30. URN schemes will allow the sequences like %20%1E or whatever, so this could
  31. be a real problem. Another thought: What if someone wants to come along an
  32. do %hhhh style encoding of UTF-16? Will this be mistaken for encoded UTF-8?
  33.  
  34. ---
  35. Gregory Woodhouse     gjw@wnetc.com
  36. home page:            http://www.wnetc.com/
  37. resource page:        http://www.wnetc.com/resource/
  38.